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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

presented to TSG for information; 

presented to TSG for approval; 

or greater indicates TSG approved document under change control. 

Y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This TS defines the service requirements from users" and operators" perspective for the support of IP multimedia 
applications through the IMS. 

IP multimedia applications are supported by IP multimedia sessions in the IM CN Subsystem. IP multimedia sessions 
use IP connectivity bearers (e.g. GPRS as a bearer). Examples of IP multimedia applications include speech 
communication, real time multimedia applications, shared online whiteboards etc. 

This TS, in general, does not standardise usage of IP multimedia applications, but instead identifies the requirements to 
enable their support. 

In order to align IP multimedia applications wherever possible with non-3GPP IP applications, the general approach is 
to adopt non-3GPP IP based solutions. 

The existing legacy tele- and supplementary services shall not be re-standardised as IP multimedia applications, and 
multimedia equivalent applications may be created with toolkits. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[I] 3GPP TS 22.003: "CS Teleservices supported by a PLMN". 
[2] Void 

[3] Void 

[4] Void 

[5] 3GPP TS 22.101: "Service principles". 

[6] Void 

[7] 3GPP TS 22. 146: "Multimedia Broadcast/Multicast Service; Stage 1 " 

[8] Void 

[9] IETF RFC 3261: "SIP: Session Initiation Protocol" 

[10] 3GPP TS 22.078: "Customised AppHcations for Mobile network Enhanced Logic (CAMEL); 

Service definition - Stage 1 " 

[II] 3GPP TS 22.057: "Mobile Execution Environment (MexE); Service description. Stage 1" 

[12] 3GPP TS 22.038: "USIM/SIM Application Toolkit (USAT/SAT); Service description; Stage 1" 
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[13] Open Mobile Alliance (OMA): OMA-RD-Parlay_Service_Access-Vl_0-20100427-A 

[14] 3GPP TR 21.905: "Vocabulary for 3GPP specifications" 

[15] IETF RFC 3966: "The tel URI for Telephone Numbers" 

[16] 3GPP TS 22.240: "Stage 1 Service Requirement for the 3GPP Generic User Profile (GUP)" 

[17] ETSI ETS 300 284: "Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) 

supplementary service; Service description" 

[19] ETSI TS 102 424: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Requirements of the NGN network to support Emergency 
Communication from Citizen to Authority" 

[20] 3GPP TS 22.173: "Multimedia Telephony Service and supplementary services" 

[2 1 ] 3GPP TS 3 1 . 1 03 : "Characteristics of the IP Multimedia Services Identity Module (ISIM) 

application". 

[22] IETF RFC 5039: "The Session Initiation Protocol (SIP) and Spam" 

http://www.ietf org/rfc/rfc5039.txt?number=5039 

[23] IETF RFC 5631: "Session Initiation Protocol (SIP) Session Mobihty" 

http://www.ietf org/rfc/rfc563 1 .txt?number=563 1 

[24] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[25] 3GPP TS 22.081: "Line Identification supplementary services; Stage 1" 

[26] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

2.2 Informative references 

[18] GSMA PRD IR.34: "Inter-Service Provider IP Backbone GuideUnes" 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [14] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 14] . 

Access independence: the ability for the subscribers to access their IP Multimedia services over any access network 
capable of providing IP-connectivity, e.g. via: 

- 3GPP accesses (e.g. E-UTRAN, UTRAN, GERAN) 

(S\ TM 

- Non 3GPP accesses with specified interworking (e.g. WLAN with 3GPP interworking, DOCSIS , WiMAX 
and cdma2000 access) 

Other non 3GPP accesses that are not within the current scope of 3GPP (e.g. xDSL, PSTN, satellite, WLAN 
without 3GPP interworking) 

Conference: An IP multimedia session with two or more participants. Each conference has a 'conference focus'. A 
conference can be uniquely identified by a user. An example for a conference could be a multimedia game, in which the 
conference focus is located in a game server. 

Conference Focus: The conference focus is an entity which has abilities to host conferences including their creation, 
maintenance, and manipulation of the media. A conference focus implements the conference policy (e.g. rules for talk 
burst control, assign priorities and participant"s rights). 
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Domain Name Owner: The entity that is noted in the Internet (i.e. ICANN or one of its subsidiaries) as owning the 
Domain Name. 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions 

IMS Inter UE Transfer: Transfer at the IMS -level of all or some of the media components of an IMS session between 
UEs under the control of the same end-user while maintaining service continuity. 

IP multimedia application: an application that handles one or more media simultaneously such as speech, audio, video 
and data (e.g. chat text, shared whiteboard) in a synchronised way from the user"s point of view. A multimedia 
application may involve multiple parties, multiple connections, and the addition or deletion of resources within a single 
IP multimedia session. A user may invoke concurrent IP multimedia applications in an IP multimedia session. 

IP multimedia service: an IP multimedia service is the user experience provided by one or more IP multimedia 
applications. 

IP multimedia session: an IP multimedia session is a set of multimedia senders and receivers and the data streams 
flowing from senders to receivers. IP multimedia sessions are supported by the IP multimedia CN Subsystem and are 
enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user may invoke concurrent IP multimedia sessions. 

Shared Domain Name: The domain name in the IMS Network-Independent Public User Identity, and which is served 
by multiple IMS Operators. 

Unsolicited Communication: Unsolicited Communication (UC) denotes bulk communication in IMS where the benefit 
is weighted in favour of the sender. In general the receiver(s) of UC do not wish to receive such communication. UC 
may comprise of, e.g., "SPam over IP Telephony (SPIT)" [22] or "SPam over IP Messaging (SPIM)". 

Further definitions are given in 3GPP TR 21.905 [14]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [14] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [14]. 

® 

DOCSIS Data Over Cable Service Interface Specifications 

WiMAX Worldwide Interoperability for Microwave Access 

TM 

NOTE: WiMAX is a trademark of the WiMAX Forum 

® 

DOCSIS is registered trademark of Cable Television Laboratories, Inc. 

cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-US A) 



Introduction 



IP has opened up a whole range of communication applications, which may allow operators to develop totally new 
value added applications as well as to enhance their existing solutions. The open architecture and platforms supported 
by IP and operating systems may lead to applications and new opportunities that are more difficult to replicate using a 
standard switched centralised solution. 

A complete solution for the support of IP multimedia applications (including voice communications) shall be available. 
The solution consists of UEs, GERAN or UTRAN radio access networks and GPRS evolved core network. One of the 
main objectives for 3GPP specifications is to ensure that the availability and behaviour of these IP applications when 
used via the 3GPP mobile access is at least as good as when used via other mobile access types. 
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High level requirements 



Support for IP multimedia sessions shall be provided in a flexible manner to allow operators to differentiate their 
services in the market place as well customise them to meet specific user needs. This shall be provided by the use of 
service capabilities in both networks and terminals, for the creation and support of IP multimedia applications. 

The following high level requirements shall be supported for IP multimedia applications: 

Negotiable QoS for IP multimedia sessions both at the time of a session establishment as well as during the 
session by the operator and the user 

Negotiable QoS for individual media components in an IP multimedia session both at the time of establishing a 
media component as well as when the media component is active by the operator and the user 

End to end QoS for voice at least as good as that achieved by the circuit-switched wireless systems shall be 
enabled 

Support of roaming, negotiation between operators for QoS and for Service Capabilities is required. Such 
negotiation should be automated rather than manual, e.g., when another operator adds new service capabilities. 

Support of roaming and interconnection shall include the capability for media to be routed optimally between 
IMS operators, i.e. according to criteria set by the operators. 

Possibility for a network operator to implement IP Policy Control for IP multimedia applications. 

IP multimedia sessions shall be able to support a variety of different media types. A set of media types shall be 
identified to ensure interoperability (e.g. default codec selection and header compression). 

Within each IP multimedia session, one or more IP multimedia applications shall be supported. It shall be 
possible to support multiple IP multimedia applications to efficiently provide a coherent and consistent IP 
multimedia service experience. Such support involves identifying which applications are invoked per subscriber, 
understanding the appropriate order of the set of applications, and resolving application interactions during the 

session. 

The possibility for IP multimedia applications to be provided without a reduction in privacy, security, or 
authentication compared to corresponding packet switched and circuit switched services. 

IMS shall be capable to provide transcoding (at least for voice sessions) where needed when two UEs do not 
support a common codec. 

Interconnection between two IMS domains shall be supported. 

Note: see also Section 10 

Roaming shall be supported enabling users to access IP multimedia services provisioned by the: 

Home Environment 

- Serving Network 

The principle of access independence shall be supported. It is desirable that an operator should be able to offer 
services to their subscribers regardless of how they obtain an IP connection (e.g. E-UTRAN, UTRAN, GERAN, 
fixed Hnes, LAN, DOCSIS®, WiMAX™ and cdma2000® access). 

Note: Access independence principle can only be ensured by 3GPP for the access technologies 3GPP has 
defined or has defined specific interworking. 

- It shall be possible for the users to access IM CN via an IP connection (e.g. GPRS, fixed lines, LAN) with 
Network Address Translation (NAT) deployed. 

- IM CN should provide support for the users to access IM CN through a Firewall (FW) with configuration 
restrictions (e.g. only HTTP allowed, port range limitation) deployed outside operators" domain. 

It shall be possible to support session-related internet applications that have been developed outside the 3GPP 
community. 
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It shall be possible to limit the view of an operator"s network topology to authorised entities. 

It shall be possible to support the multiple UEs associated with a single IMS service subscription. It shall be 
possible to share one Public User Identity between multiple UEs. It shall also be possible to identify the 
individual UEs with separate Public User Identities. IMS shall be able to route sessions towards the identified 
UE(s), e.g. based on UE capability, User preference and/or Network preferences. 

It shall be possible for a service to identify and interact with a specific UE even when multiple UEs share the 
same single Public User Identity. A UE shall be capable to identify and interact with a specific UE even when 
multiple UEs share the same single Public User Identity, except when the UE supports only limited capabilities 
and thus is unable to become engaged in a service that requires such functionality. Examples include a telemetry- 
only capable UE that only supports the capabilities for point-to-point communication. 

The IMS shall be capable to access information about the state of a user's access connection, whether the user is 
roaming or not. According to operator policies this information may be provided to applications. 

The IMS shall be capable to access user location information, whether the user is roaming or not. According to 
operator policies this information may be provided to applications. 

Where required (e.g. by regulation) the IMS shall provide the capability for the user to indicate to the network 
that a communication is malicious. 

Note: see also MCID in [20]. 

Where required (e.g. by regulation) the IMS shall provide the capability for the network, on behalf of the user, to 
reject incoming communications from users who have restricted the presentation of their originating identity. 

Note: see also ACR in [20]. 

The IMS shall support the capability of enabling early media for an IMS multimedia session. The capability for 
such early media shall be applied towards both calling and called user. 

Note: Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by 
the called user. 



6 Standardised service capability approach 

IP multimedia applications shall, as a principle, not be standardised, allowing operator specific variations. It shall be 
possible to enable rapid service creation and deployment using service capabilities. 

It is important that commercially available IP multimedia applications are supported. In general compatibility shall be 
with these IP multimedia applications instead of building 3GPP-specific solutions. 

The following options shall be available in the 3GPP standards to enable service delivery: 

an architectural framework shall be created that enables maximum flexibility in the end user device and network 
servers, similar in concept to that used in the Internet. 

This framework shall enable an operator to efficiently deploy IP multimedia applications in a network-agnostic 
manner without having to wait for these applications or additional enabling technology, to be standardised in 
3GPP. 

service capabilities (enhanced to control IP multimedia applications), which will allow IP multimedia 
applications to be deployed in a vendor independent manner 

CAMEL [10], MExE [11], SAT [12] and OSA [13], should be improved to support IP multimedia appHcations, 
e.g. additions to APIs, service capability features, service capability servers, user profile etc. 

the IM CN Subsystem user related data to be stored in a standardised format and to be managed and accessed 
using standardised mechanisms of the 3GPP Generic User Profile (GUP) [16]. 

mechanisms which allow the network or the application to understand the limitations of the mobile and thereby 
take appropriate actions. 
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Note: There is a concern that with a large variety of toolkits to create applications, service interworking between 
terminals and networks may be compromised and needs to be addressed. 



User service requirements 



IP multimedia sessions provide the ability for users to invoke IP multimedia applications to send and receive (where 
applicable) voice and data communications, even when roaming. This includes interworking with existing voice and 
data networks for both fixed (e.g. PSTN, ISDN, internet etc.) and mobile users. 

The IM CN subsystem shall support interworking with existing fixed and mobile voice and IP data networks, including 
PSTN, ISDN, Mobile and Internet. 

It shall be possible to have basic voice calls between IMS users and users in CS domain/PSTN-style networks. When an 
IM session originates or terminates in a CS telephony call, the experience of the CS telephony network user should not 
substantially differ from that of a call between two CS telephony network users in terms of aspects such as the delay to 
set-up communications and the total permissible delay in transporting speech between the end users. The IM CN 
subsystem does not necessarily have to support all services offered by the CS telephony network. 

7.1 Identifying IP multimedia application subscriptions 

There is no requirement to support standardised subscription mechanisms for IP multimedia applications. 

IP multimedia applications may require to be provisioned and configured by users and operators. Since the source and 
variety of IP multimedia applications may not be standardised, the specific feature codes to provision, enable and 
configure IP multimedia applications may not be standardised either. . 

Note: The standardised service capabilities, personalised Internet web pages and evolving IP mechanisms may be 
used to allow user (self) provisioning, configuration and enabling of IP multimedia applications. 

7.2 Access to the IM CN subsystem 

7.2.0 General 

IMS, complying with the principle of access independence, supports IP multimedia applications via IP multimedia 
sessions over a multitude of IP Connectivity Access Networks. These include e.g. E-UTRAN, UTRAN, GERAN, fixed 
line, I-WLAN, DOCSIS®, WiMAX™ and cdma2000® access. 

7.2.1 Access control 

The IM CN subsystem shall be able to verify at any time that the user is entitled to use the resources of the IM CN 
subsystem. 

7.2.2 IMS Registration and De-registration 

In order to be able to access services from the IM CN Subsystem a UE shall register on the IM CN Subsystem. 
A UE that supports IMS shall be able to register on the IM CN Subsystem. 
A UE may support automated IMS registration, e.g. when gaining access to the PS domain. 
A UE that supports IMS shall be able to de-register from the IM CN Subsystem. 
The network operator shall be able to de-register a UE from the IM CN Subsystem. 
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7.3 Capability negotiation 



The IMS shall provide the capability for IP multimedia applications (whether it is an application of a user or the 
network) to negotiate their capabilities to identify and select the available media components, QoS etc. of IP multimedia 
sessions. It shall be possible for the capability negotiation to take place on invocation, acceptance and during an IP 
multimedia session (e.g. following a change in UE capabilities, change in media types etc.). Capability negotiation may 
be initiated by the user, operator or an application on behalf of them. 

In order to support the user's preferences for IP multimedia applications, the capability negotiation shall take into 
account the information in the user profile whenever applicable. This includes the capability to route the IP multimedia 
session to a specific UE, when multiple UEs share the same IMS service subscription. 

7.4 Redirecting of IP Multimedia sessions 

The IMS shall support the capability for the user, or the network on behalf of the user, to identify an alternative 
destination for an IP multimedia session or individual media of an IP multimedia session. Redirection to alternative 
destinations may be initiated by the sending party, receiving party or the network on their behalf. It shall be possible for 
redirection to be initiated at various stages of an IP Multimedia session. For example: 

Prior to the set up of an IP Multimedia session 

During the intial request for an IP Multimedia session 

During the establishment of an IP Multimedia session 

While the IP Multimedia session is ongoing 

Redirection can be applied for all Multimedia sessions unconditionally or it can be caused by any of a set list of events 
or conditions. Typical causes could be: 

Identity of the caller 

Location or presence of the calling or called party 

If the called party is already in a session 

If the called party is unreachable or unavailable in some other way 

If the called party does not respond 

After a specified alerting interval 

User"s preference on routing for specific IP Multimedia session based on the capabilities of multiple UEs sharing 
the same IMS service subscription. 

Time of day. 

There are other causes that could be applied that do not require standardisation. 

7.5 Invoking an IP multimedia session 

7.5.0 General 

The user shall be able to invoke one or more IP multimedia sessions. The user shall also be able to activate concurrent 
IP multimedia applications within each IP multimedia session. 

7.5.1 Identification and addressing 

Subscribers within the IMS shall be identifiable in originating and terminating sessions by means of one or multiple 
Public User Identities. The Public User Identity shall: 

be able to be assigned to more than one Private User Identity; 
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be administered by the network operator and not be changeable by the user; and 

- be globally reachable. 

The Private User Identity shall be able to be assigned to more than one Public User Identity. 

Both telecommunication numbering and Internet addressing schemes shall be supported as Public User Identities. 

The Pubhc User Identity shall utilise either the SIP URI scheme (as defined in IETF RFC 3261 [9]) or the Tel URI 
scheme (as defined in IETF RFC 3966 [15]). 

Both SIP URIs and Tel URIs can be used to convey E. 164 [26] numbers; 

The network operator shall be able to use in the Public User Identity either the same E.164 [26] number used for CS 
speech telephony (TSl 1 [1]) or a difl'erent E.164 number. 

Both telecom and internet numbering and addressing schemes shall be supported as public identities. IP multimedia 
communication establishment (both originating and terminating) depending on originator shall be able to be based on 
E.164/TELURI (e.g. tel:+4412345678) [15]or SIP URI (sip:my.name@company.org) [9]. It shall be possible to assign 
several public identities for one subscription. 

Whilst not required for routing between terminals within the IMS, it should be possible for the IMS network to: 

recognise and treat URIs, containing IM' or 'Pres' prefixes, received from other networks supporting such 
prefixes; and 

insert an IM', 'Pres' or 'mailto' prefix to an outgoing URI to enable routing to the correct addressee in external 
networks supporting such prefixes. 

It shall be possible for the network operator to guarantee the authenticity of a Public User Identity presented for an 
incoming session to a user where the communication is wholly across trusted networks. 

NOTE 4: This is equivalent to the calling line presentation services CLIP [25] in the telephony networks. 

A terminating IMS entity may receive the original destination identity provided by the originating entity. 

NOTE 5: This enables the address originally input by the subscriber to be available at the destination even when it 
has been translated e.g. from a free phone or premium rate service identifier. 

7.5.2 Negotiation at IM session invocation 

It shall be possible for the capability negotiation to take place at the time of the IP multimedia session invocation. Refer 
to subclause 7.3 for further details on capability negotiation on IP multimedia session invocation. 



7.5.3 Emergency communications 



The requirements for Emergency communications are contained in [5] for PLMN specified by 3GPP and in [19] for 
NGN broadband accesses. 



7.5.4 Information of a Called Party 



A calling party (A) shall be able to request information regarding whether the called party (B) is a premium rate 
number or international number. 

Based on the information, the calling party (A) could exercise the option of either continuing or terminating the call. 

The HPLMN of the calling party (A) shall be able to provide information to a calling party (A) regarding whether the 
called party (B) is a premium rate number or international number. 

Based on the information provided, the calling party (A) could exercise the option of either continuing or terminating 
the call. 
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7.5.5 Void 

7.6 Handling of an incoming session (by the terminating entity) 

7.6.1 Automatic re-routing 

IMS shall provide the capability to handle communications rejected (e.g. due to unavailability of PSTN/ISDN 
resources) using re-routing. 

7.6.2 Presentation of session originator identity 

The IMS shall present the identity of the session originator (see 7.5.1). The network shall suppress the presentation of 
the identity when requested by the session originator. 

Operator policies (e.g. requirements for support of emergency communications) may over-ride the user request for 
suppression. 

7.6.3 Negotiation of an incoming session 

Interaction with the user profile shall be supported, and additionally direct interaction with the user may be required. 
Refer to subclause 7.3 for further details on capability negotiation on an incoming IP multimedia session. 

7.6.4 Accepting or rejecting an incoming session 

It shall be possible for the user to either accept, reject, ignore or re-direct an incoming IP multimedia session. Further, it 
shall also be possible for the user to accept only a subset of the offered media, not have any of the media offered to him 
at all etc. 

7.6.5 Handling of an incoming session addressed to an unallocated 
identity 

In case of an incoming session addressed to an identity administered by the operator but not allocated to a user or a 
service, the IMS shall be able to reject, re-route or trigger service logic to that incoming session. 

7.7 Handling of an ongoing session 

7.7.1 User modification of media in an ongoing session 

The user shall be able to negotiate the addition or deletion of media components of IP multimedia applications during 
an IP multimedia session. Refer to subclause 7.3 for further details on capability negotiation during an IP multimedia 
session. 

7.7.2 Suspending and resuming of an ongoing session 

It shall be possible for the user to suspend an IP multimedia session, and resume that IP multimedia session at a later 
time. 

7.7.3 Presentation of identity of connected-to party of a session 

It shall be possible to present to the originator of a session the identity of the party to which she is connected (see 7.5. 1). 

However, the connected-to party shall be able to request that her identity is not revealed to the originator of the session. 

Operator policies (e.g. requirements for support of emergency communications) may over-ride the user request for 
suppression. 
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7.8 Ending a session 

The user shall be able to end an IP multimedia session at any time during the session. The network may end an IP 
multimedia session at any time during the session (e.g. in failure conditions). 

7.9 Void 

7.1 Handling of conferences 

7.10.1 General 

Conferences allow users participating in the conference to communicate with all other participants simultaneously. A 
conference has a "conference focus", that controls the conference. 

Note that a user, participating in the conference, depending on the conference policy may be allowed to communicate 
with the focus (e.g. to request invitation of another user into the conference). 

7.10.2 User requirements 

The following minimum user requirements for conferences exist: 

A user shall be able to request the creation of a conference. 

A user shall be able to request to join an existing conference. 

A user participating in the conference shall be able to request modification of the conference (e.g. add/remove 
media, manipulation of data streams, add/remove participants) depending on the conference policy. 

A user participating in the conference shall be able to request termination of the conference, depending on the 
conference policy. 

A user participating in the conference shall be able to receive information from the conference focus (e.g. 
participants in conference, participants joining or leaving the conference) 

It shall be possible for a user to transfer the invited participants to other focus aware conference user(s) prior to 
leaving the conference if the user has invited participants to the conference. 

7.10.3 Network-based Conference Focus 

For the case where the "conference focus" is based in the network, the following requirements apply: 

The home network shall be able to provide the "conference focus". 

The visited network shall be able to provide the "conference focus", controlled by the home network , and 
subject to roaming agreements. 



7.1 1 Handling of multicast services 



Multicast services allow IMS users and service providers to send multimedia to a group of IMS users simultaneously in 
an unidirectional way of communication. The underlying network may be able to support mechanisms that optimize the 
delivery of multimedia to the individual members of that group (e.g. MBMS [7]) 

Note: an example for applicability of multicast services could be the IMS based 'Push to talk over Cellular' 
service, that is being standardised by OMA. 

An IMS application located on an application server in the network shall be able to request that multimedia is 
sent to a group of IMS users, which are specified by this request. 

Depending on the capabilities of the underlying network IMS shall be able to use optimized mechanisms of the 
network (e.g. multicast capabilities such as MBMS [7]) for the delivery of multimedia to the group of IMS users. 
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7.12 Support for Local Numbers in the IMS 

A number or short code originating from a UE may correspond to a local number based on HPLMN/VPLMN's 
numbering plan, a service number in the HPLMN/VPLMN, or a private numbering plan. 

A number or short code may have a local context indicator (LCI) added to it. The value of an LCI helps the HPLMN to 
route the call and, if necessary, route the call to the country/VPLMN/private network of origin. The LCI may include: 

access specific information consist of e.g. country code plus network code, country code plus area code, or an 
identification of a private numbering plan; 

the home domain; 

an indication that UE does not support processing of the dialled string; or 

any other value entered by the user. 

If the HPLMN cannot interpret the number or short code based on the included LCI, the HPLMN may apply policies to 
translate local numbers to globally routable identity and to route the call. 

The HPLMN shall analyse the received number and route the call as follows: 

If the number or short code has an LCI, the HPLMN should interpret the short code to a globally routable URI or 
E. 164 [26] number according to the value of the LCI, and then correctly route the call. If the HPLMN is unable 
to resolve or route the received number then an error message shall be returned to the originating UE. 



7.1 3 User determined user busy 



The network shall support the capability of a user to reject an incoming IMS session with an indication of "user busy". 
This indication may be used by the network as a trigger for certain services e.g. Call Forwarding on Busy. If the session 
rejection is propagated back to the originator, the "user busy" indication must be provided as the cause of the rejection. 

The conditions for user determined "user busy" include: 

• the session is offered to a single contact that rejects with a "user busy" indication; or 

• the session is offered to multiple contacts with a single public identity, and one contact rejects with a "user 
busy" indication on behalf of the set of contacts; or 

• the session is offered to multiple contacts; and 

none of the contacts progress the session; and 
one or more of the contacts rejects with a "user busy" indication. 
Note: A contact is e.g. a terminal, a UE, or some other kind of equipment in the user premises. 

7.14 IMS Inter-UE Transfer 

The IMS shall be able to provide IMS Inter-UE Transfer between: 

different UEs connected via the same IP -CAN, 

- different UEs connected via different 3GPP IP-CANs, 

different UEs connected via a 3GPP IP-CAN and a non-3GPP IP-CAN (e.g. fixed line connectivity), 

different UEs connected via different non-3GPP IP-CANs. 

In addition the IMS shall be able to provide IMS Inter-UE Transfer from UEs connected via an IP-CAN to ICS entities 
that provide interworking with UEs in the CS Domain. 

Note 1 : In this case it might not be possible to retrieve the session after it has been transferred. 
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Note 2: When interworking with the UEs in the CS domain, the available lUT features are limited by the UE"s 
capabilities. 

The following requirements are applicable for IMS Inter-UE Transfer. 

The IMS shall support the capability to transfer/retrieve some or all of the media components to/from different 
IMS UEs belonging to the same or different user(s) while providing continuous service experience to these users. 
In order to provide continuous service experience to the user, the receiving IMS UE capabilities (e.g. display 
resolutions, codecs capabilities, and access network data rate, etc.) shall be taken into consideration and the 
transferred sessions adapted accordingly. 

It shall be possible to provide continuous service experience when the session is transferred between IMS 
UEs of different capabilities. 

It shall be possible to transfer some or all media components to the target IMS UE(s) belonging to the same or 
different user(s) that are subscribed to the same operator. This can be initiated either directly from the controlling 
IMS UE or on request from the IMS UE where the media will be transferred. 

It shall be possible to replicate some or all media components to the target IMS UE(s) belonging to the same or 
different user(s) that are subscribed to the same operator. This can be initiated either directly from the controlling 
IMS UE or on request from the IMS UE where the media will be replicated. 

Replication / transfer of some or all media components to target IMS UE(s), belonging to the same or to different 
user(s) that are subscribed to the same operator, shall not be performed when the remote end (e.g. the source of 
the media) of the session restricts such operation. 

It shall be possible to transfer service control related to all media components to the target IMS UE that belongs 
to the same user and has subscription with the same operator. This can be initiated either directly from the 
controlling IMS UE or on request from the IMS UE where the control will be transferred. 

Note 3: Transfer of service control and transfer / replication of media components are independent of each other. 
This means the above requirements include the case where certain media components are transferred / 
replicated to the target IMS UE(s) whilst the related service control remains in the source IMS UE or is 
transferred to the target IMS UE, and the case where service control is transferred to the target IMS UE 
whilst the controlled media components remain in the source IMS UE. 

Inter-UE Transfer shall be subject to operator policy. 

It shall be possible to discover information on ongoing IMS sessions on different IMS UEs belonging to the lUT 
e.g. available IMS sessions, media components, controUer/controllee capability. 



IMS shall support the capability to add /delete media components across different UEs belonging to the same or 
different user(s) that are subscribed to the same operator, while providing continuous service experience to these users. 

An IMS user shall be able to control media components of an IMS session between different UEs as following: 

Add new media components to different UEs at session setup and session modification. 

Remove media components of an ongoing multimedia session from different UEs. 

IMS shall support the capability to share control of media components among multiple UEs belonging to one or more 
users that are subscribed to the same operator. Shared control of media components may be exclusive (i.e. only one UE 
has the control at a time) or simultaneous (i.e. more than one UE has the control at the same time). 

It shall be possible for the network to authorise shared control of media components among multiple IMS users. 

It shall be possible for the IMS user controlling the session to allow one or more IMS users in the session to share 
control of media components. 

Note 4: Inter-UE transfer use case as defined by IETF can be found in [23]. 
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7.15 Prevention of Unsolicited Communication in IIVIS (PUCI) 

7.15.1 High level requirements 

IMS should provide means to identify and act on unsolicited communication. 

Solutions for prevention against unsolicited communication shall not have negative impact on the services provided by 
IMS. 

PUCI should provide means for cooperation between operator" s networks. 

IMS should provide means for a user to inform the network of an unsolicited communication. 

7.15.2 Detection of Unsolicited Communication 

Depending on Operator policies IMS should support capabilities that enable IMS to detect that an IMS session is 
unsolicited and classify as UC. These capabilities should apply to all IMS based services and apply to realtime (e.g. 
voice, video ...) and to non-realtime (e.g. messaging ...) IMS traffic. 

IMS should support capabilities that enable a terminating party to report IMS sessions as UC. 

The method of reporting UC may be dependent on the IMS service. 

Reporting should be possible irrespective of whether an originiating party has withheld its identity (e.g. by referring to 
the last call). 

7.15.3 Prevention of Unsolicited Communication to the terminating party 

Depending on Operator policies IMS should support capabilities to indicate to a terminating party that an IMS session 
has been classified UC. 

Depending on Operator policies IMS should support capabilities to protect a terminating party from IMS sessions that 
have been classified UC. 

7.15.4 Notification of UC to the originating party 

Depending on Operator policies IMS should support capabilities that allow notifying an originiating party that a 
performed or attempted communication to the terminating party has been classified as UC. 

7.1 5.5 Conveying information on UC to other networks 

Depending on Operator policies IMS should support capabilities that enable the IMS of a network to convey 
information on detected UC in an IMS session to an other IMS on the path of that IMS session 

8 Interworking requirements 

8.1 General 

The IMS shall support the capability for interoperability with the following: 

- PLMN CS domain, 

- PSTN/ISDN networks. 
Packet Cable network, 

- Internet. 
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Other non 3GPP networks providing IP Multimedia sessions. 
The scope of this interoperability may result in a limited service capability. 

8.2 Interworking with PLMN CS Domain 

The IMS shall support conveyance of voice calls and multimedia services between IMS users and users in CS domain 
(within the limits set by the CS domain). 

If more than one IMS party is involved in a communication with a PSTN party/parties, the communication between the 
IMS parties shall not be adversely impacted by the presence of a PSTN party. 

Note: That this boundary may still be subject to regulatory requirements associated with communications with 
the PSTN including, but not limited to, lawful interception of voice calls and multimedia services, and 
number portability. 

The boundary interworking shall be able to convey the information associated with the services listed below: 

CLIP/CLIR; 

Call Forwarding. 

Also due to regulatory reasons the subscriber identity may be required to be conveyed via the IMS-CS/PSTN 
boundary to enable calling line identification services on both sides. 

Support of: 

Call barring. 

Call waiting/hold, 

MPTY, 
on the boundary interface is for further study. 

8.3 Interworking with PSTN/ISDN networks 
8.3.0 General 

Interworking between IMS and PSTN/ISDN networks shall be supported. PSTN/ISDN networks in this context refer to 
legacy PSTN/ISDN and TISPAN NGNs supporting PSTN/ISDN Emulation. 

Note: TISPAN NGN supporting PSTN/ISDN Emulation provide to the end-user the same experience as a 
legacy PSTN/ISDN and from a interconnection perspective the TISPAN NGN behaves like an IMS 
network. 

As a network option and depending on inter-operator policies, the IMS shall support transit of traffic between 
PSTN/ISDN networks. 



8.3.1 Overlap Signalling 



Support for overlap signalling in the IMS is an option limited to the interworking with PSTN/ISDN networks that use 
overlap signalling. Support of this option shall be based on inter-operator policies at the interconnection point. The IMS 
of operators not supporting overlap signalling shall not be affected. 

In the absence of such inter-operator policies, networks interworking with IMS shall select appropriate signalling 
mechanisms to complete the call without any impact on IMS networks not supporting overlap signalling.. 

Note 1 : PSTN/ISDN networks that convert overlap signalling to en-bloc, are considered to be networks that do 
not use overlap signalling. 
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In the cases where a PSTN/ISDN network, based on inter-operator policies, provides overlap signalling into the IMS, 
the following requirements shall be taken into account: 

For calls terminating in the IMS, conversion of overlap signalling to en-bloc shall take place within the IMS 
domain. 

Impact on the IMS shall be minimized. 

The service experience for the end-user shall be similar to the PSTN/ISDN. 

When the IMS network supports transit of traffic, transit of overlap signalling may be supported towards 
destination networks, if the policy permits overlap signalling towards those. 

Note 2: Overlap signalling support should not be linked to E. 164 [26] numbering schemes. 

Note 3: Overlap signalling is not generated or terminated by an IMS UE it is only generated or terminated by 
devices within the PSTN/ISDN networks. 



8.3.2 Subaddressing (SUB) 



Where public telecommunication numbers are used, the IMS may support the Subaddress (SUB) service that allows the 
called (served) user to expand his addressing capacity beyond the one given by the public telecommunication number. 

Note: Subaddressing is required for interoperability with existing users. 

Subaddressing is required when at least one of the users services are provided from an ISDN. 

The IMS may support the interoperability of Subaddressing with the PSTN/ISDN networks and vice versa. 



8.3.3 User-to-User Signalling (UUS) 

The IMS may support the User-to-User Signalling (UUS) service that enables a calling party to send and/or receive a 
limited amount of User-to-User-Information (UUI) to/from a called party in association with a communication. 

Note: UUS is required for interoperability with existing users. 

UUS is required when at least one of the users services are provided from an ISDN. 

The IMS may support the interoperability of User-to-User Signalling services with the PSTN/ISDN networks and vice 
versa. 

Only UUS service 1 with an implicit request is supported [17]. 

8.4 Void 

8.5 Interworking with Packet Cable 

The IMS shall support the capability for interoperability with Packet Cable networks. The scope of this interoperability 
may result in a limited service capability. 

8.6 Interworking with Internet 

The IMS shall support interworking with the Internet. 

8.7 Voice Interworking with Enterprise IP-PBX 

For voice IP-PBX-based services provided to a UE with the following conditions: 

the IP-PBX is connected to the mobile operator network as an IMS Application Server, 
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the interconnection between mobile operator and Enterprise is via a QoS-enabled IP connection, and 

a UE that connects via the Enterprise has a subscription in the IMS domain; 

the following requirements apply: 

The mobile operator"s IMS shall control the VoIP session for interworking with the Enterprise IP-PBX. 

VoIP session control shall always be returned to the mobile operator following interactions with the Enterprise 
IP-PBX. 

Interfaces between mobile operator and Enterprise shall be secured. 

A UE provisioned in the mobile operator" s IMS shall be able to receive services from an interconnected 
Enterprise IP-PBX. 

When transcoding is needed to establish a session between UEs that support wide band codecs, transcoding shall 
be between wide band codecs in accordance with agreements between the mobile operator and the Enterprise. 

When a session using wide band codecs is transferred from the IP-PBX to the IMS, the IMS shall maintain the 
ongoing session using wide band codecs in accordance with mobile operator and Enterprise policy, when the use 
of wide band codecs is enabled in the network. 

The mobile operator" s IMS shall provide VoIP service without a reduction in privacy, security, or authentication 
compared to corresponding service in the mobile operator macro network. 

The mobile operator" s IMS shall be able to receive information about the state of the UE access connection from 
the Enterprise. 

Subject to local regulatory requirements, the mobile operator"s IMS shall be able to receive the UE location 
information from the Enterprise. 

Subject to local regulatory requirements, the mobile operator"s IMS shall be able to receive indication of 
malicious communication from a user in the Enterprise. 

The mobile operator"s IMS shall be able to transfer UE VoIP sessions between UEs in the Enterprise, subject to 
mobile operator and Enterprise agreements. 

Subject to local regulatory requirements, user location information provided by the Enterprise shall be used by 
the mobile operator"s IMS for Emergency calls. 

The mobile operator shall be able to restrict which IP-PBX services are available to a UE. 

The mobile operator shall be able to charge for providing IP-PBX services to a UE. 

Continuity of services provided to a UE shall be supported when the UE moves between an Enterprise 
environment and a cellular environment. 

The mobile operator shall be able to control which entity takes precedence in case there is a conflict in terms of 
which entity provides a particular service (e.g. voice mail) to a UE. 

All configuration changes performed by the Enterprise that affect the interworking with the mobile operator shall 
be performed in agreement with the mobile operator. 

Interworking between the Enterprise IP-PBX and the mobile operator IMS shall comply with IMS Service 
Control Interface (Section 4.2.4 in [24]). 

Feature interaction between the existing mobile operator features and the Enterprise IP-PBX features is 
addressed through bilateral agreement and is beyond the scope of 3GPP. 
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9.1 



IP Addressing 



General 



The Operator of an IMS infrastructure may base the implementation on IPv4 only, IPv6 only or both. The choice is an 
operator option. 

The IMS may support UEs using IPv4 only, IPv6 only or both at an IP -based User-Network Interface. The choice is an 
operator option. 

9.2 IP addressing for cdma2000 access to IMS 

The IMS may support UEs using simultaneous multiple IP addresses. 



10 Interconnection requirements 
10.1 Introduction 

IMS interconnect represents the interconnection of IMS functionality between 2 IMS networks over an underlying IP 
infrastructure. 

A distinction can be made between: 

Direct IMS interconnect, and 

Indirect IMS interconnect. 

Direct IMS interconnect is interconnection of IMS functionality between 2 IMS networks using a common IP 
interconnect network that is not SIP aware. In this case there is only one IMS-NNI (see Figure 10.1). 




IMS-NNI 



Figure 10.1 Basic IIVIS interconnect with single IMS-NNI 

Indirect IMS interconnect is interconnection of IMS functionality between 2 IMS networks using a common IP 
interconnect network that is SIP aware. In this case there are two or more IMS-NNIs (see Figure 10.2). One or more of 
the intermediate networks may also be IMS networks providing 'transit' functionality. 




IMS-NNI 



IMS-NNI 



Figure 10.2 Indirect IMS interconnect with multiple IMS-NNIs 
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NOTE: An IMS NNI could also be applied between an IMS network and another SIP based network if that SIP 
based network conforms to IMS specifications on the interconnect interface. 

An IMS network B delivers originating IMS services (e.g. least cost routing, service dependant routing, call barring, 
number translation, break-out) to a network A if the services are delivered for a session that arrives in the IMS network 
B over an IMS NNI from network A (Figure 10.3). 
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Figure 10.3: delivery of originating IMS application services across an IMS-NNI 

An IMS network C delivers terminating IMS services (e.g. bulk rerouting, redundancy, profile based reachability, 
number translation) to a network D in case the services are delivered for a session that shall continue from the IMS 
network C over an IMS NNI to network D (Figure 10.4). 



Terminating IMS 
Application 





Service 




IMS ^ 
Network 

c 




► (IMS) 
Network 

D 


Session Setup 



IMS-NNI 



Figure 10.4: delivery of terminating IMS application services across an IMS-NNI 

10.2 IP interconnect 

The IP connection used for IMS IP interconnect shall be generic such that it can support all combinations of core 
network interconnection. E.g. the IP interconnection shall be shared between the IMS interconnection and the CS IP 
interconnection. 

It shall be possible to handle the inter-connection of all services over this generic IP interface. The handling of security 
and charging shall also be generic for all IP inter-connect scenarios. 

10.3 IMS network interconnect 

The following requirements apply at the interconnection point (IMS NNI) between two different IMS networks or 
between an IMS network and a SIP based network that conforms to the IMS specification at the interconnect interface. 

The IMS network and intermediate networks shall support the capability for service interoperability by means of service 
interworking requirements defined in section 8. 

The IMS network and intermediate networks shall support the capability for service identification, when such 
information is available. 

The IMS intermediate networks shall be able to apply operator defined policy at the interconnection point. 
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The IMS intermediate networks shall support the capability for control of the session resources when two different IMS 
networks are connected which have different IP addressing schemes. 

The IMS network shall support both bilateral interconnection between two networks and multilateral interconnection 
(e.g. GSMA IPX [18]) provided by intermediate network(s). 

The IMS network and intermediate networks shall support service aware interconnection. 

Note: service awareness could be based on service identification, media parameters etc. 

An IMS network shall be able to deliver IMS originating application services and terminating application services to 
other networks interconnected over the IMS NNI . 

An IMS network shall be able to deliver IMS originating application services and/or terminating application services to 
users that are registered to another network. 

The IMS network and intermediate networks shall support codec negotiation across one or multiple interconnects to 
minimise transcoding (and preferably eliminate it) to provide the highest quality service to the user. 

If two UEs, belonging to two IMS networks, do not support a common codec for voice service session, the network 
and/or intermediate networks shall be capable to provide transcoding functionality at the interconnection point. 
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Annex A (informative): 

Example IP multimedia application scenarios 

The following example scenarios describe the personalised handling of individual media in multimedia applications 
(note that this list is neither complete nor exhaustive):- 

1) The user is in a voice communication, and receives an incoming IP video communication. The user decides not 
to accept the communication, but diverts the incoming video to a messaging system. Further, the user is given an 
indication that there is a video message in his mail box 

2) The user is in a voice communication, and receives an incoming video communication. The user decides to 
accept the communication but wishes to switch between the two communications. 

3) The user is idle in a network and not involved in a communication. The user modifies his user profile to divert 
all voice communications other than those from high priority, pre-identified callers (e.g. his boss). In this 
scenario all emails and text messages continue to be received regardless of the sender. 

4) On receiving a communication, the calling party's identity is displayed (if not restricted) and user shall be able to 
decide whether to accept the communication, or divert to a messaging system. The user shall be able to request 
media handling of the communication (e.g. media splitting to different destinations, media conversion). 

5) The user is busy in a communication when receiving an incoming communication, but responds to the 
originating party that he will respond later. The user may request that the originating party's details (if not 
restricted) are stored with a reminder in user's profile. 

6) Hi-fi sound (nuances, character of voice) 
Person(s) : Marketing Manager, Rita 

Situation : She is at a launch party for some customers in London. In the break she listens to her messages and 

one from another customer in Tokyo gets her attention. He just wants her to call, but doesn"t say if it is urgent or 

not. 

Solution : Due to the excellent sound quality of the terminals involved and the messaging system, she picks up 

the faint irritation in his voice and decides to call him immediately. It was urgent and she could remedy the 

situation easily by emailing the information from her built in PDA storage. The customer was relieved as he was 

just going in to a very important meeting. 

Benefit(s) : Good sound quality gives more information to base judgements on, i.e. emulates real life meetings 

better. 

7) Stereo sound (nuances, character of voice plus positions, sound-scapes) 
Person(s) : Purchase Officer, Gustavo 

Situation : Participates in a conference to discuss purchase of a new kind of steel for the factory in Rio. As he is 
on the road he calls from his hotel room in Sydney. The conference is in the head office in Rio. The local 
department has invited the two final contenders to have them argue their cases. The two companies are 
positioned at the different ends of the table. One of the groups is presenting and mentions something about 
deliveries. A side remark is barely audible, 'we can"t deliver that quality and that quantity this year !' Who gave 
this remark? 

Solution : The excellent sound quality together with the stereoscopic sound gives Gustavo the information he 
needed. It was the other group that gave the remark. The decision was made for him at that point. He gave the 
order to the presenting group right after they finished a very good presentation that told him everything he 
wanted to hear. The setup at the head office was done with two synchronized UEs at each end of the table. 
Benefit(s) : Stereoscopic sound gives even more information than just hi-fi sound to base judgements on, i.e. 
emulates real life meetings better. 

8) Conference/chat with "private rooms" 

Person(s) : A project team at an IT company: Rick, Diana, Ted, Sven and Liu 

They are based in different cities. 

Situation : The project team has one of their weekly reporting meetings using their mobile communicators. In the 

middle of the meeting. Rick and Diana get lost in a lengthy arguing on some detailed design matters that bores 

the rest of the team. Ted, the moderator, finds that it is nevertheless necessary to give Rick and Diana some 

minutes to finish their discussion, so he decides to not interrupt them. At the same time Sven remembers that he 

need to remind Liu to send a report to him on the latest findings from her research work. 

Solution : The team use a conference/chat service with the new facility "private rooms". This allows Sven to 
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direct a few words in privacy to Liu. Sven activates easily this feature by the GUI of his communicator. Liu is 
immediately notified by the GUI of her communicator that Sven is now talking privately with her (this is 
necessary to avoid embarrassing misunderstandings that could occur if Liu would answer Sven in the "common 
room" instead of in the new "private room" that Sven has created). 

Since the voices of all conference members are synthetically mapped in a stereophonic projection, Liu is able to 
hear what Sven is saying, even though he speaks simultaneously with the other team members (the 
communicator will not automatically adjust the sound volume of the "common room", since it cannot know if 
Liu is more interested in Sven's comments or in continuing to listen to the other team members). 
Benefit(s) : This service emulates virtual presence in a conference room in the best possible way without adding 
more visionary technologies like holographic projections, etc. The synthetic stereophonic sound projection 
provides good possibilities for a conference member to discriminate unwanted voices even if the meeting 
situation is informal and spontaneous and everyone are talking at the same time. The flexible possibilities to 
create one or more "private rooms" make it easy to make private comments to selected colleagues. The easy-to- 
use and fast responding GUI makes the needed end-user effort to create a new "room" so low, that it feels natural 
to use the function even for exchanging just a few quick words. 

Alternative use : Exchange the IT project team with a gang of teenagers that are planning what to do in the 
weekend. The service works perfectly well also in that scenario and provides the same benefits. 
Additional features : Easy GUI controlled addition of new participants (can be initiated by any of the 
participants), including addressing, notification/invitation, etc. (cf. "outgoing call" in PSTN). GUI notification of 
new incoming session invitations (cf. "incoming call" in PSTN) and possibility to choose action as desired 
(incorporate the "calling party" in the existing conference session, creating a new separate session, rejecting the 
invitation, diverting it to a messaging system, etc.) Whiteboarding and/or application sharing. 

9) Multiplayer mobile gaming with voice channel 

Person(s) : Joe (age 15), Blenda (age 14), Fredric (age 15) and all their "cyber friends" in the Shoot-n-Shout 

v.14.0 community 

Situation : In the legendary multiplayer game Shoot-n-Shout v.14.0 the most popular game mode is a team 

competition. The idea is simply to shoot down the members of the concurring teams. There are always a lot of 

active game sessions in CyberSpace. At a webAVAP service operated by the game application provider, 

interested potential players can choose a game session and also find other gamers to form a team with. There is a 

text chat service where potential team-mates can learn to know each other. 

Joe, Blenda and Fredric meet on the webAVAP chat and decide to form a team to take up the fight in one of the 

Shoot-n-Shout sessions. They are preparing a game strategy in advance through the text chat service, but when 

they have started the battle it takes too long time to type text, so they the will need another way to communicate 

with each other. 

Solution : The game application provider makes use of a conference/chat service with "private rooms" in order to 

provide a multi-player voice service to the players of Shoot-n-Shout. When a game starts there is one "common 

room" where all players can talk (or rather shout) to each other and one "private room" for each team. Players in 

a team can also dynamically create more "private rooms" if they only like to talk to one (or a few) of their 

friends. (See the conference/chat scenario for details.) 

The volume (and stereophonic position) of the players voices when they are using the "common room" is 

controlled so that it matches the virtual surroundings in the game environment. As an example, players that are 

behind a wall will only be heard as a vague whisper in the distance. 

Benefit(s) : A voice channel will enhance the gaming experience for several popular network games. 

10) Application sharing with voice commentary 

Person(s) : Marketing Manager, Rita and Media expert, Jones 

Situation : The launch of a new campaign for some customers in London. Last minute feedback is that one of the 

customers is expecting the latest gadget to be included, even if its only a prototype. Rita knows it"s not included 

in the presentation and she has no information with her. 

Solution : Rita calls Jones, the media guru they employed for design of their important presentations. He has the 

information and some pictorials. He sends them over into Rita"s PowerPoint application and they edit the new 

slide together as they discuss the textual information to be included. 

Benefit(s) : The process is extremely interactive and the session takes only 5 minutes thanks to the broadband 

connection and the fact that they don"t need to Ping-Pong the pictures and the text back and forth. (Emphasize 

mobile or fixed access as required). The customer is happy and a Letter of Intent is signed. 

Comments : By adding voice and pictures in an interactive session we achieve both effectiveness and interaction, 

two desired components. 

11) Emergency location with voice conversation, navigation and picture transfer 
Person(s) : Ma Beth, her children and the pet dog Bobby 

Situation : The family is out driving in the country side and they take a turn on the slippery country road a bit too 
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fast. They slide down into the ditch. Bobby the dog in the back of the van gets a heavy box of books on top of his 
left paw. It may be broken, and you can tell it certainly hurts from the loud yelps that come out in a rushed 
stream. The rest of the family is ok. They were all buckled up. 

Solution : Ma Beth reaches for her communicator as soon as she has recovered from the initial shock. She calls 
1 12 (91 1 or similar). The answer comes after 23 seconds and the operator immediately confirms the identity and 
the location of the van. Ma Beth is a bit taken aback by this quick information and has to think for awhile, then 
confirms the location as possibly correct. She then states the problem and she gets connected to a vet that asks a 
few pertinent questions. She can show a close up picture of the dog"s left paw and the vet confirms a possible 
(95%) broken leg just above the paw. He gives a few quick instructions and sends her a map of the closest 
emergency animal hospital. The map shows her current position and soon displays the quickest way to get to the 
hospital. Well there, Bobby is taken care of and things are looking up. Even the kids are smiling now that the 
dog is calm and free from pains, and he looks so funny with his little cast. 

Benefit(s) : The initial call transfers emergency information to the operator automatically. This ensures minimum 
delay to correct action. The Communicator transfers the picture that gives enough information to make a very 
accurate and fast assessment of the situation. Then the map transfer and display on the terminal together with the 
current position gives clear information and directions for Ma Beth to drive and make the right turns at every 
corner. In her still half-shocked state she can drive to the hospital without hesitation about where to go. Very 
reassuring for all parties including the dog that gets fastest possible help. 

Comments : The call is initially just a voice call but evolves with the best of positioning in emergency situations 
and navigational aid together with picture and graphics transfer. 

12) The Real Virtual Theatre and Foyer Chat room - Fixed Network example 
Person(s) : Theatre going 'cultural' group with one member (Bob) in a hospital bed. 

Situation : The group is watching the play and are utterly fascinated by the first act. When they come out into the 

foyer in the break they remember Bob. They really want to share this first act with him since they know 

Shakespeare"s Midsummer Night"s Dream is his favorite. 

Solution : Bob uses the theatre"s online streaming service via the hospital network. (At only half the price of a 

theatre ticket!). The play displays in color and stereo surround sound on his bedside TV set. In the break his 

friends call him up from the theatre chat room. The chat room is equipped with 3D sound pick up and local 

display screens with streaming facilities. They set up the streaming from one of the screens to be synchronized 

with Bob"s bedside equipment. Their voices are also mixed into the sound streams as they talk. Bob now gets 

both the playbacks from the first act and his friends" voices in 3D surround sound. Bob"s voice is projected close 

to the screen as if he was standing leaning on the bench right there. His voice is very clear and full of emotions 

as he speaks to the various playbacks. Both parties can control the playbacks and watch their own selection in a 

second window on the screen. 

Benefit(s) : Bob can pick up every nuance in the lively discussion, including the whispered comments from Greta 

in the back. The group is almost feeling Bob"s presence because of the emotional clarity and distinct position of 

his voice. As both parties have control and visibility of the streaming sessions, it is very effective and very 

interactive. 

Comments : Experiential services are sought after. This one can be a bit exclusive because of the equipment 

requirements, but the uses are many. 

13) Mobile synchronized MM container 

Person(s) : The married couple Bill and Christine and their daughter Linda 

Situation : Bill is on a business travel to Spain. He calls his wife Christine every night using his MMM terminal. 

Often Christine is answering at home using her Screenphone, but this particular evening Christine has arranged a 

baby-sitter for their children so she could go to a restaurant with some friend. When Bill is calling, she is sitting 

on the commuter train on her way home. Bill often show some pictures during his calls (both live pictures 

showing the environment where he is at the moment and pictures that he has been taking during the day with his 

separate digital camera). 

Today, their talk starts off as a common voice conversation. After a while Bill likes to show Christine the lovely 

sunset view that he can see from his hotel room, so he make some snapshots with the built-in camera of his 

terminal and sends them in real-time mode to Christine. Christine likes to show one of them to their little 

daughter Linda when she comes home. 

Solution: With a quick gesture on the touchscreen of Christine"s MMM terminal, she instantly moves the 

selected picture from the real-time session window to the 'multimedia container' icon. All the contents of the 

'container' is automatically mirrored between the MMM terminal and her home server. In this way, Christine can 

easily pick up the picture from her Screenphone at home. If Linda is at sleep when Christine comes home, she 

can wait until tomorrow. 

Benefit(s) : The 'multimedia container' can be used for every type of MM content that one likes to have available 

both at home and at another location. This 'container paradigm' is very intuitive and stimulates the use of images. 
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video clips etc. for a multitude of purposes. The 'container' can be used both for transferring content from the 
MMM terminal to the home server (as in this scenario) and in the opposite direction. 
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Annex B (Informative): Business models use cases 

The IMS supports agreements between the access network operator and the network operator providing IMS services 
(IMS operator). 

The IMS shall be able to offer services to users that are attached to access networks owned by another operator. 

The service offering may be restricted by the capabilities of the access network and the agreement between the access 
network operator and the IMS operator. 

The IMS shall support at least the following operator's domain relationships: 

a) Access network to IMS relationships 

a.l) Access network and the IMS it connects to, belong to the same operator as shown in figure B.l. 



Intra-operator 
Relationship a 





Figure B.l 

a.2) Access network and the IMS it connects to, belong to different operators having an interconnection as 
shown in figure B.2. 



Relationship b 




Access network 
Operator B 





b) IMS level relationships 



Figure B.2 



b.l) The IMS (e.g. 3GPP or NGN) to which the access network connects and the Home IMS (e.g. NGN or 
3GPP) which provides the IMS services belong to different operators as shown in figure B.3. 




Figure B.3 

b.2) The IMS (e.g. 3GPP or NGN) to which the access network connects and the Home IMS (e.g. NGN or 
3GPP) which provides the IMS services are the same as shown in figure B.4. 
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Relationship d 





Figure B.4 

b.3) The IMS (e.g. 3GPP or NGN) to which the access network connects and the Home IMS (e.g. NGN or 
3GPP) which provides the IMS services belong to the same operator as shown in figure B.5. 




Figure B.5 

An IMS operator shall be capable of connecting to other network operators via: 

an interconnect model where agreements are established between two operators; 

an interconnect model where intermediate network(s) can provide interconnect on behalf of multiple operators 
(and may be based on an agreement between the operators and their intermediate network provider). 

A single IMS operator shall be able to choose to support either of the interconnect models, or both of the interconnect 
models simultaneously. 
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Annex C (Informative): 

Basic communication cases for IIVIS networks 

A basic communication case can be described on a per IMS basis by stating the IMS entry point and an exit point for 
the communication as shown in figure C.l. 

The following general types of entry/exit point can be identified: 

Access (for communication to from terminals); 

Interconnect to non-IMS network; 

Interconnect to other IMS; 

Internal network resource (e.g. a conference bridge for conferencing services). 

As a general rule a network based on IMS shall support the following basic communication cases on a per network 
basis, as shown in Table C.l. 

Table C.l 



From 
(entry point) 


To (exit point) 


Access Network 


Interconnect to other 
IMS 


Interconnect to 
non-IMS network 


Internal Network 
Resource 


Access Network 


Required 


Required 


Required 


Required 


Interconnect to other 
IMS 


Required 






Required 


Interconnect to 
non-IMS network 


Required 




Required 


Required 


Internal Network 
Resource 


Required 









It is not precluded that other, more complex communication cases may be provided by service level concatenation of 
basic communication cases, e.g. by means of call diversion services. 
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Non-IMS 
Network 




Figure C.I : Graphical representation of supported basic communication cases 
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Annex D (normative): 

Access to IMS via non-3GPP access 

This annex defines additional specific requirements for access to IMS via non-3GPP access. 

These requirements shall not apply to terminals having a 3GPP access. 

For non-3GPP-only terminals with neither ISIM nor USIM, the IMC may be used to access the IMS via a non-3GPP 
access technology. However, if ISIM [21] is present it shall be used to access IMS or if ISIM is not present but USIM 
[24] is present, USIM shall be used to access IMS. 
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Annex E (informative): 

Example use cases for IIVIS Inter UE Transfer (i.e. 

transfer/replication/sharing) 

Users of communication services will increasingly use different devices with different communication capabilities to 
meet their communication needs. Users may wish to initiate, transfer, manipulate, or otherwise maintain the 
simultaneous real time streaming of multimedia components (e.g. video, speech, audio) between multiple devices for a 
variety of reasons. For example, users may wish to control: 

the coordinated delivery of simultaneous multimedia streams to multiple devices owned by the same user (e.g. to 
take advantage of the different video and audio capabilities of the different devices: high definition television, 
surround sound stereo, home speaker phone, etc) 

shared multimedia content in real time across multiple devices owned by others (who may be in different 
locations) 

This annex defines some of the use cases for IMS Inter UE Transfer (i.e. transfer/replication/sharing), examples of 
which are given below (note that this list is neither complete nor exhaustive): 

1) Shared control of session across multiple IMS users 
Jill calls Jane to share and discuss a video. 

- Jane and Jiir's controls are synchronized so they share the seamless video experience. Both UEs are capable of 
shared control. 

Either Jill or Jane can pause the shared video to provide comments. Either of them can resume the video when they are 
ready to do so. 

- Jane and Jill need to be authorized by network after Jill allows Jane to share control. 

2) Transfer of service control 

Jane is having a multi-media call (audio/video stream) on her mobile with Jill while coming home. After arriving at 
home, Jane transfers the video stream and service control to another device that belongs to her (e.g. a PC that is IMS 
capable and on which she is logged in), but keeps the audio on her mobile to keep the conversation private from the 
other people in the room. 

3) Media Replication 

Jane is watching a video clip on her cell phone, which another family member (Jane"s Dad) starts to watch, so they are 
watching together and talking about it. Jane"s Dad wants to continue watching the video clip on another device (e.g. 
Jane's PC that is IMS capable and on which she is logged in), so he requests replication of the video component to 
Jane's PC. 



4) Video replication 

Steve, president of a wine-tasting club schedules a video documentary to start at an agreed time for all club members, so 
that they can watch it from their home and chat together about it while watching. In this case, all sessions are 
synchronized, and Steve is able to control the video playing: he can put the video on pause for all members in the same 
time. 
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Annex F (Informative): Voice interworking with Enterprise 
IP-PBX reference model 

The Reference Model provided in Figure F. 1 is for the retail model in which the mobile operator manages and 
authenticates the 3GPP mobile device and authenticates the IP-PBX access to IMS services. The wholesale model, in 
which an Enterprise purchases 3GPP mobile devices and services in bulk, is not in scope. 




Figure F.I : Reference Model 

Figure x.l shows the relationship between the mobile operator and the Enterprise. The mobile operator network 
comprises the IMS network that connects to the PSTN and the SS7 network as well as Presence and Location 
information, for example. One or more 3GPP access networks are also provided by the mobile operator macro network. 

The Enterprise network comprises fixed and/or wireless access networks (e.g. WLAN) and the IP-PBX. The wireless 
access networks can be either 3GPP access networks or non-3GPP access networks (e.g., WLAN) and the fixed access 
network can be any wired IP access in the Enterprise. The Enterprise network is connected to the mobile operator core 
network via a managed IP network using two kinds of connections: 

The Enterprise access network is connected to the mobile operator core network via managed IP network. 

The Enterprise IP-PBX is connected to the mobile operator IMS network via managed IP network. 

Access and IMS authentication of the 3GPP mobile devices connected via the Enterprise access network are done via 
this managed IP network. IMS authentication of IP-PBX devices connected via the Enterprise access network may also 
be done via this network if such devices are provisioned in the mobile operator network. This enables IP-PBX services 
to be offered via the mobile operator IMS to the 3GPP mobile devices in the mobile operator network or Enterprise 
network and to the IP-PBX devices in the Enterprise network. 

The Enterprise can leverage the business/roaming relationship of the mobile operator with other mobile operators. This 
enables 3GPP mobile devices to access both mobile operator and Enterprise applications from any Enterprise location 
so the Enterprise requires a business relationship with only a single mobile operator and not with multiple mobile 
operators. Therefore, no additional business models to support roaming are needed. 
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services, AI30-06 


7.3.0 


7.4.0 


ServID 


SP-32 


SP-060432 


- 


????8 


0041 


2 


Rel-7 


F 


Support of Local Numbers in the 
IMS 


7.3.0 


7.4.0 


TEI7 


SP-32 


SP-060323 


SI -060611 


22.228 


0040 




Rel-8 


B 


Network requested IMS session 
initiation 


7.3.0 


8.0.0 


TEI8 


SP-33 


SP-060463 


SI -060855 


22.228 


0043 




Rel-8 


A 


Support of local numbers in the 
IMS - clarification and 


8.0.0 


8.1.0 


IMS2 
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corrections 








SP-37 


SP-070657 


S1 -070991 


????8 


0047 


2 


Rel-8 


A 


Identification of a specific UE 
when multiple UEs share a 
single Public User Identity 


8.1.0 


8.2.0 


TEI8 


SP-37 


SP-070658 


SI -071 294b 


????8 


0048 




Rel-8 


B 


TISPAN Service and Capability 
requirements for Common IMS 


8.1.0 


8.2.0 


TISCAP- 
R8 


SP-38 


SP-070844 


SI -071 683 


????8 


0054 




Rel-8 


F 


NAT support in Common IMS 


8.2.0 


8.3.0 


CIMS8- 
TIS 


SP-38 


SP-070844 


SI -071 684 


????8 


0056 




Rel-8 


D 


Corrections to definition of 
"Access Independence" 


8.2.0 


8.3.0 


CIMS8- 
TIS 


SP-38 


SP-070844 


SI -071 780 


????8 


0060 




Rel-8 


F 


Any IP version support 


8.2.0 


8.3.0 


CIMS8- 
TIS 


SP-38 


SP-070844 


51-071866 


22.228 


0063 




Rel-8 


F 


Corrections based on LS from 
TISPAN and Action from SA 
Plenary 


8.2.0 


8.3.0 


CIMS8- 
TIS 


SP-38 


SP-070846 


SI -071 787 


22.228 


0049 




Rel-8 


B 


User determined user busy 


8.2.0 


8.3.0 


CIMS8- 
TIS 


SP-38 


SP-070862 


SI -071 924 


22.228 


0053 




Rel-8 


C 


Optimal Media Routing Support 
for IMS Sessions 


8.2.0 


8.3.0 


IPinterc 


SP-38 


SP-070862 


SI -071 926 


22.228 


0059 


2 


Rel-8 


B 


IMS Interconnection requirement 


8.2.0 


8.3.0 


IPINTERC 


SP-39 


SP-080031 


SI -0801 84 


????8 


0062 


4 


Rel-8 


F 


Enhancements on access to the 
IMS 


8.3.0 


8.4.0 


CIMS8- 
TIS 


SP-39 


SP-080031 


SI -0801 67 


????8 


0064 


2 


Rel-8 


D 


Removal of abbreviations and 
definitions already included in 
21.905 


8.3.0 


8.4.0 


CIMS8- 
TIS 


SP-39 


SP-080205 


- 


????8 


0066 


3 


Rel-8 


F 


Corrections to Interworking with 
PSTN/ISDN networks 


8.3.0 


8.4.0 


CIMS8- 
TIS 


SP-39 


SP-080040 


SI -080238 


????8 


0067 


1 


Rel-8 


B 


Additional requirements for IMS 
interconnection 


8.3.0 


8.4.0 


IPINTERC 


SP-39 


SP-080031 


SI -0801 83 


????8 


0068 


- 


Rel-8 


C 


Emergency communication for 
fixed NGN 


8.3.0 


8.4.0 


CIMS8- 
TIS 


SP-39 


SP-080040 


SI -080328 


????8 


0069 


1 


Rel-8 


B 


Clarification of requirements for 
IMS interconnection 


8.3.0 


8.4.0 


IPINTERC 


SP-40 


SP-080298 


SI -080610 


22.228 


0070 


2 


Rel-8 


B 


Service Requirements for 
Common IMS 


8.4.0 


8.5.0 


CIMS 3G 
PP2 


SP-42 


SP-080775 


SI -08321 5 


22.228 


0048 


1 


Rel-8 


F 


Requirements for capability 
enabling early media 


8.5.0 


8.6.0 


TEI8 


SP-42 


SP-080769 


SI -083442 


22.228 


0075 


1 


Rel-8 


B 


IMS Credentials requirements 


8.5.0 


8.6.0 


CIMS 3G 
PP2 


SP-42 


SP-080775 


SI -084052 


22.228 


0077 




Rel-8 


F 


Correction of wrong reference 


8.5.0 


8.6.0 


TEI8 


SP-42 


SP-080780 


SI -08441 6 


????8 


0079 


2 


Rel-9 


B 


IMS IDT -Inter UE Transfer - 
Definitions 


8.6.0 


9.0.0 


IDT 


SP-42 


SP-080780 


SI -08421 5 


????8 


0080 


2 


Rel-9 


B 


IMS IDT Inter UE Transfer 
Service Requirements 


8.6.0 


9.0.0 


IMS SCC- 
IDT 


SP-42 


SP-080782 


SI -084406 


????8 


0084 


2 


Rel-9 


B 


Service requirements for 
Prevention of Unsolicited 
Communication in IMS (PUCI) 


8.6.0 


9.0.0 


PUCI 


SP-43 


SP-090084 


SI -0901 85 


????8 


0085 


1 


Rel-9 


F 


IMS IDT Inter UE Transfer 
Service Requirements 


9.0.0 


9.1.0 


IMS SCC- 
IDT 


SP-43 


SP-090084 


SI -090341 


????8 


0088 


1 


Rel-9 


B 


lUT between an IP CAN and 
3GPP CS Domain 


9.0.0 


9.1.0 


IMS sec 
IDT 


SP-43 


SP-090086 


SI -090340 


????8 


0087 


3 


Rel-10 


C 


Requirements for a focus aware 
conference users before leaving 
the conference 


9.1.0 


10.0.0 


TEI10 


SP-45 


SP-090652 


SI -093373 


????8 


0098 


3 


Rel-10 


B 


Use Cases for Transfer of 
Control 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-090652 


SI -093292 


22.228 


0099 


3 


Rel-10 


B 


Use Case for Shared Control of 
session across Multiple IMS 
users 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-090652 


SI -093375 


????8 


0100 


2 


Rel-10 


B 


Use Case for Media Replication 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-090652 


SI -093378 


22.228 


0101 


2 


Rel-10 


B 


Clarification of session setup / 
modification requirements 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-090652 


SI -093475 


22.228 


0102 


2 


Rel-10 


B 


Shared Control of media flows 
across multiple UEs 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-090652 


SI -093379 


22.228 


0103 


3 


Rel-10 


B 


Transfer of Control / Media 
Replication requirements 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-090652 


SI -093291 


22.228 


0105 


2 


Rel-10 


B 


Use Case for video replication 


10.0.0 


10.1.0 


elMS SC 
C-IDT 


SP-45 


SP-0906e0 


SI -093284 


????8 


0109 


3 


Rel-10 


C 


Add the feature of completing 
dialed number to global form 


10.0.0 


10.1.0 


TEI10 


SP-45 


SP-090483 


SI -093296 


????8 


0113 


3 


Rel-10 


B 


Receiving the original 
destination identity 


10.0.0 


10.1.0 


TEI10 


SP-46 


SP-090846 


SI -0941 29 


22.228 


0122 


- 


Rel-10 


B 


Add support for the mailto 


10.1.0 


10.2.0 


TEI10 
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scheme to IMS 








SP-46 


SP-090846 


SI -094481 


????8 


0119 


1 


Rel-10 


F 


Announcement towards the 
terminating user 


10.1.0 


10.2.0 


TEI10 


SP-46 


SP-090846 


SI -094282 


????8 


0121 


2 


Rel-10 


B 


IMS-Unallocated identity 
handling 


10.1.0 


10.2.0 


TEI10 


SP-46 


SP-090846 


SI -094280 


????8 


0120 


2 


Rel-10 


B 


Request information of a called 
party 


10.1.0 


10.2.0 


TEI10 


SP-46 


SP-090847 


SI -094279 


22.228 


0116 


3 


Rel-10 


F 


Clarification to lUT service 
control requirement 


10.1.0 


10.2.0 


IMS SC 
elDT 


SP-46 


SP-090847 


SI -094285 


22.228 


0124 


2 


Rel-10 


F 


Inclusion of an IETF reference 
for lUT 


10.1.0 


10.2.0 


elMS SC 
C-IDT 


SP-49 


SP-1 00575 


SI -102053 


22.228 


0131 




Rel-10 


A 


Removal of references to 3GPP 
OSA 


10.2.0 


10.3.0 


TEI10 


SP-49 


SP-1 00577 


SI -102387 


22.228 


0127 


1 


Rel-10 


F 


Alignment of Transfer of Control 
requirements 


10.2.0 


10.3.0 


IMS SC 
elDT 


SP-49 


SP-1 00581 


SI -102407 


22.228 


0132 


2 


Rel-11 


B 


IMS application services across 
IMS-NNI 


10.2.0 


11.0.0 


IPXS 


SP-50 


SP-1 00803 


SI -103009 


????8 


0133 


- 


Rel-11 


B 


Conferencing Support in a 
VPLMN 


11.0.0 


11.1.0 


OSCAR 


SP-50 


SP-1 00799 


SI -103200 


????8 


0135 


2 


Rel-11 


B 


Additions to IMS application 
services across IMS-NNI 


11.0.0 


11.1.0 


IPXS 


SP-50 
















Problem with figures 10.3 and 
10.4 (introduced by CR0135r2 
above) solved 


11.1.0 


11.1.1 


IPXS 


SP-51 


SP-1 10164 


SI -110074 


22.228 


0139 


. 


Rel-11 


D 


Editorial change to figure 10.3 
and 10.4 Clause 10.1 


11.1.1 


11.2.0 


IPXS 


SP-51 


SP-1 10172 


SI -110428 


22.228 


0141 


2 


Rel-11 


B 


lUT Privacy considerations 
associated with remote end user 
and restricting copyrighted 
content. 


11.1.1 


11.2.0 


TEI11 


SP-52 


SP-1 10375 


SI -11 1390 


????8 


0145 


1 


Rel-11 


B 


New annex for VINE reference 
model 


11.2.0 


11.3.0 


VINE 


SP-52 


SP-1 10375 


SI -11 1396 


????8 


0144 


4 


Rel-11 


B 


Voice Interworking with 
Enterprise IP-PBX (VINE) 
Requirements 


11.2.0 


11.3.0 


VINE 


SP-52 


SP-1 10376 


SI -11 1354 


????8 


0143 


2 


Rel-11 


B 


FW traversal support in 
Common IMS 


11.2.0 


11.3.0 


TEI11 


SP-52 


SP-1 10379 


SI -11 1346 


????8 


0126 


3 


Rel-11 


B 


IMS Network-Independent 
Public User Identities 


11.2.0 


11.3.0 


INIPUI 


SP-53 


SP-1 10581 


S1-112192 


????8 


0142 


2 


Rel-11 


B 


Information of called party for 
INIPUI 


11.3.0 


11.4.0 


INPUI 


SP-53 


SP-1 10582 


SI -112026 


22.228 


0149 




Rel-11 


F 


Re-introduction of an approved 
high level requirement 


11.3.0 


11.4.0 


TEI11 


SP-53 


SP-1 10632 


SI -112373 


22.228 


0147 


2 


Rel-11 


F 


Clarification of UE for VINE 


11.3.0 


11.4.0 


VINE 


SP-56 


SP-1 20285 


S1-121414 


22.220 


0154 


2 


Rel-11 


A 


Clarification on emergency calls 
from CSG cell by non-CSG 
member 


11.4.0 


11.5.0 


TEI9 


SP-58 


SP-1 20864 


SI -124448 


22.228 


0179 


1 


Rel-11 


A 


Removal of operator initiated 
IMS registration 


11.5.0 


11.6.0 


TEI8 
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